Description

Closes #2591.

Adds an optional continue_on_error: bool field on every step.
When set to true and the step fails, the engine records the
result (exit_code, stderr, status) into steps.<id>.output and
continues to the next sibling step instead of halting the run.
Downstream if, switch, or gate steps can then branch on
{{ steps.<id>.output.exit_code }} to route the recovery path.

This is the shape @mnriem proposed in the issue discussion —
it composes with primitives that already exist (the exit code
is already captured, the expression engine already resolves it,
and if/switch/gate are already available). The only gap
was that a non-zero exit hard-stopped the pipeline before any
downstream step could evaluate it.

Canonical usage

- id: heavy-thing
  type: command
  integration: claude
  command: speckit.heavy-thing
  continue_on_error: true

- id: check-result
  type: if
  condition: "{{ steps.heavy-thing.output.exit_code != 0 }}"
  then:
    - id: review
      type: gate
      message: "Step failed (exit {{ steps.heavy-thing.output.exit_code }}). Retry or skip?"
      on_reject: skip
  else:
    - id: next-thing
      command: speckit.next-thing

Engine

WorkflowEngine._execute_steps now consults the step config when
a step returns StepStatus.FAILED:

• Gate aborts (output.aborted) always halt the run — operator
  decisions take precedence over the flag.
• Otherwise, if continue_on_error: true, log a
  step_continue_on_error event and proceed to the next sibling.
• Otherwise, behave as before: log step_failed, set
  RunStatus.FAILED, and return.

Exactly one event per failure-resolution path is logged so the
log timeline is unambiguous: either the run continued past the
failure or it halted.

Validation

_validate_steps rejects non-bool values for continue_on_error.
Coerced strings like "true" are not accepted so authoring
mistakes surface at validation time rather than silently
changing run semantics.

Default behaviour preserved

When continue_on_error is omitted, every code path is
byte-equivalent to before this change. Existing workflows see no
difference.

Verdict coverage (from the issue discussion)

Fully unattended retry-on-transient (e.g. retry a 429 at 3 AM
without operator attendance) is intentionally out of scope here.
The skip and abort verdicts work without a human; the
retry verdict still pauses for one at the gate. A future
loop/retry-count primitive or an auto-approving gate type could
close that gap on top of this mechanism without further engine
changes — happy to follow up on that in a separate issue if
useful.

Testing

• Tested locally with uv run specify --help
• Ran existing tests with uv sync && uv run pytest
  → 2967 passed, 35 skipped (was 2960 before; +7 new
  tests added in this PR).
• Tested with a sample project: ran a 3-step workflow where
  the middle step exits non-zero. Without
  continue_on_error, run halts at the failing step (as
  before). With continue_on_error: true, the failing step
  records exit_code and the third step executes. A
  downstream if branching on
  {{ steps.flaky.output.exit_code != 0 }} routes into a
  recovery gate cleanly.

New test coverage

TestContinueOnError in tests/test_workflows.py:

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (described below)

Used Claude Opus to draft the engine change, the test suite, the
docs section, and this PR body. The shape (continue_on_error

• exit-code-as-API + branch on it via existing primitives) was
  proposed by @mnriem on the issue thread; this PR implements that
  proposal. Code, tests, and design decisions were human-reviewed
  before submission.